<p>An issue is raised when using a fallback empty object with the logical OR (<code>||</code>) or nullish coalescing (<code>??</code>) operators when
spreading values in object literals.</p>
<h2>Why is this an issue?</h2>
<p>When spreading values in JavaScript object literals, falsy values like <code>null</code>, <code>undefined</code>, <code>false</code>,
<code>0</code>, or empty strings are safely ignored and don’t add any properties to the resulting object. This means that fallback patterns like
<code>{…​(foo || {})}</code> or <code>{…​(foo ?? {})}</code> are unnecessary.</p>
<p>The JavaScript spread operator in object literals has built-in safety for falsy values. When you write <code>{…​null}</code> or
<code>{…​undefined}</code>, no properties are added to the object, and no error is thrown. This makes defensive fallback objects redundant.</p>
<p>Using unnecessary fallbacks creates several problems:</p>
<ul>
  <li> <strong>Code bloat</strong>: The extra fallback object adds unnecessary characters and complexity </li>
  <li> <strong>Reduced readability</strong>: The defensive pattern suggests there might be a real risk when there isn’t one </li>
  <li> <strong>Maintenance overhead</strong>: More code to read, understand, and potentially modify </li>
  <li> <strong>Performance impact</strong>: Creating an empty object as a fallback has a small but unnecessary runtime cost </li>
</ul>
<p>The pattern likely comes from developers being overly cautious or from experience with array spreading, where <code>[…​null]</code> would indeed
throw an error. However, object spreading behaves differently and is more forgiving.</p>
<h3>What is the potential impact?</h3>
<p>This issue primarily affects code maintainability and readability. While not a security or reliability concern, unnecessary fallback objects make
the codebase more verbose and can mislead other developers about the actual behavior of the spread operator in object literals.</p>
<h3>How to fix?</h3>
<p>Remove the unnecessary fallback empty object when spreading in object literals. The spread operator safely handles falsy values without throwing
errors.</p>
<h4>Non-compliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
const object = {...(foo || {})}; // Noncompliant
</pre>
<h4>Compliant code example</h4>
<pre data-diff-id="1" data-diff-type="compliant">
const object = {...foo};
</pre>
<h3>Documentation</h3>
<ul>
  <li> <a href="https://github.com/sindresorhus/eslint-plugin-unicorn#readme">eslint-plugin-unicorn</a> - Rule <a
  href="https://github.com/sindresorhus/eslint-plugin-unicorn/blob/HEAD/docs/rules/no-useless-fallback-in-spread.md">no-useless-fallback-in-spread</a>
  </li>
  <li> MDN - Spread syntax - <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax">Official
  documentation about the spread operator in JavaScript</a> </li>
  <li> MDN - Falsy values - <a href="https://developer.mozilla.org/en-US/docs/Glossary/Falsy">Explanation of falsy values in JavaScript</a> </li>
  <li> MDN - Logical OR operator - <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Logical_OR">Documentation for
  the logical OR operator</a> </li>
  <li> MDN - Nullish coalescing operator - <a
  href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing">Documentation for the nullish coalescing
  operator</a> </li>
</ul>
